项目地址：MindForge
MindForge 是我用 Coding Agent 持续构建的一个 local-first、approval-first personal knowledge compiler。它的核心思想是：AI 可以生成
ai_draft，但只有经过人工显式批准的内容，才能进入human_approvedknowledge library。
Coding Agent 通常不缺写代码的能力，麻烦在于它可以一直写下去。
给它一个方向，它会继续补功能、测试、文档、治理和重构。commit 越来越多，报告也越来越完整，甚至每一轮都有 dogfood 和 review。产出在增长，项目却未必更接近真实用户价值。
MindForge 在这个过程中逐渐成形，也在一次次验证后收窄了范围。它最开始只是一个很常见的想法：做一个 AI 个人知识库。把文章、笔记、网页、资料导入进来，让 AI 帮我总结、分类、组织，再支持检索、Wiki 和导出。
这个方向很容易扩张。RAG、embedding、vector DB、Graph、Entity、Community、Sensemaking、Obsidian 自动写入，每一个都听起来合理。更麻烦的是，用 Coding Agent 做这些东西时，它们不会显得很贵。Agent 可以一直继续干活。
后来我发现，一句更强的 prompt 解决不了这个问题。Prompt 负责告诉 Agent 这一次做什么，Harness 则约束它在整个项目里怎样持续做事、何时停下来。
MindForge 最终积累下来的是一套 harness：SPEC 和产品边界、rules 和红线、workflow、gates、evidence、fresh clone dogfood、recursive remediation、docs reset，以及最后的 user validation gate。
MindForge 最终收敛成的，也不是一个 RAG 系统，不是自动知识图谱，不是 Obsidian 自动写入器。它更准确的定位是：
local-first、approval-first personal knowledge compiler。
主路径是：
Source / Import
→ ai_draft
→ Review
→ explicit approval
→ human_approved
→ Library
→ BM25 Recall / Wiki
→ Export
MindForge 还没有完成真实用户验证，本文记录的是它如何从持续扩张走向收敛。
它现在比较诚实的状态是：工程 dogfood 通过，real provider main path 通过，但真实用户验证尚未完成。下一步不是继续堆功能，而是找 3 到 5 个真实用户验证。
我以为在做知识库，后来发现是在做确认机制
最开始，我脑子里的 MindForge 是“AI 帮我整理资料”。
这句话很顺，也很危险。因为它省略了一个关键问题：AI 整理出来的东西，谁来确认？
早期 pipeline 跑起来以后，source 可以导入，provider abstraction 有了，FakeProvider 可以生成结构化结果，knowledge card 也能写出来。看到第一批卡片时，我的直觉是兴奋的。标题、摘要、标签、要点都有了，一个 AI 知识库好像正在成形。
但很快我开始不舒服。
如果 AI 读了一篇文章，生成了一张卡片，这张卡片到底是什么？
它可能总结得很好，也可能遗漏前提。它可能把原文里很弱的判断写得很确定，也可能把我并不认同的观点整理得很漂亮。如果这些内容自动进入知识库，后面的检索、Wiki、图谱和导出都会进一步放大它的可信感。
它会从“AI 生成的候选内容”，变成“我的知识系统里的一条记录”。
这一步不能自动发生。
所以 MindForge 后来最重要的设计，不是某个模型，也不是某个页面，而是两个状态：
ai_draft
human_approved
ai_draft 不是知识。
human_approved 才是知识。
AI 可以生成 ai_draft，但不能替我确认什么是知识。human_approved 必须来自人工显式 approval。
这是 Harness 的第一层：产品边界。
一旦这条边界立住，后面的系统就有了约束。Library 只消费 approved cards。Recall 默认查 approved cards。Wiki 从 approved cards 生成。Export 只导出 approved cards。pipeline 不能直接把 AI 输出写成正式知识。
这两个状态不是普通字段，而是产品边界。
AI 产品不要只设计生成能力，也要先设计确认边界。尤其是知识、判断、记忆这类长期系统，自动化越强，越需要明确什么不能自动化。
为什么先用 BM25
做知识工具，很容易想到 RAG。
我也想过。embedding、vector DB、chunking、retriever、reranker，这些词放进项目介绍里会很顺，也更像一个“AI 项目”。
但 MindForge 没有从 RAG 开始。它先用了 BM25。
不是因为 BM25 更先进，而是因为它在当时更诚实。
那时真正要验证的问题不是“语义检索够不够高级”，而是：
已批准的卡片能不能被找回？ 检索范围是不是安全？ 结果为什么出现，能不能解释？ 不接外部服务，主路径能不能跑？ 测试能不能稳定覆盖 recall 行为？
BM25 足够回答这些问题。它本地运行，不需要 embedding，不需要 vector DB，不需要额外模型调用。它的行为也更容易解释和测试。
如果我一开始就做 RAG，项目会显得更先进，但可能把产品问题藏起来。你会开始调 chunk、调 embedding、调 prompt、调 rerank，但用户是否愿意 review，approved knowledge 是否有用，Wiki 是否真的帮他们回忆，这些问题仍然没有答案。
没有 gate 的自动化，只是在更快地制造不确定性。
BM25 不是终局。它只是这个阶段更诚实的选择。它让 MindForge 先把 local-first、approval-first 的主路径跑清楚，而不是一开始就把系统复杂度推高。
FakeProvider 只能证明工程链路
MindForge 很早引入了 FakeProvider。
这是一个正确设计。它让项目可以在没有网络、没有真实 API key、没有成本的情况下跑起来。source 能进 pipeline，pipeline 能生成结构化 draft，approval 能被测试，Library、Recall、Wiki、Export 都能串起来。
FakeProvider 是 harness 的重要组成部分。
它能验证工程闭环：导入能不能走通，ai_draft 状态有没有守住，approval 是否必须显式触发，没有真实模型时 demo path 是否安全可用。
但 FakeProvider 也差点让我误判进度。
当 fake dogfood 跑得很顺时，我会自然产生一种感觉：主路径已经通了。命令能跑，页面能走，状态能变，测试能过，报告也能写。
工程上，它确实通了。
但产品上，还没有。
FakeProvider 不能证明真实 LLM 输出质量。不能证明 AI draft 值得 review。不能证明用户愿意批准。不能证明 Wiki 有用。更不能证明一个真实用户会把它放进自己的工作流。
所以后来我给 FakeProvider 的定位越来越严格：它可以验证工程闭环，但不能证明产品价值。fake dogfood 是证据，但它只证明 fake path 下的工程连通性，不能替代 real provider dogfood，更不能替代真实用户验证。
主路径做出来以后，问题才具体
FakeProvider 之后，MindForge 开始补 Web / CLI 主路径。
这一步很必要。一个只在内部脚本里跑通的系统，和一个用户能通过 Web Setup、Import、Review、Library、Recall、Wiki、Export 走完的系统，不是同一个东西。
主路径一出来，问题也变得更具体。
有些问题不是 backend 对不对，而是用户能不能理解下一步。Setup 里 provider 状态是否清楚，Review 入口是否好找，导入后用户是否知道 card 只是 draft，approval 动作是否足够明确，Export 是否让人误以为会写真实 Obsidian vault。
这些问题都不是宏大架构问题，但它们决定产品是否可用。
内部 workflow、dogfood、review 和 docs reset 的作用，是把 Agent 拉回主路径：用户从哪里进来，在哪里停住，哪一步缺证据，哪一个 claim 还没有对应实现。
如果只有 prompt，Agent 很可能会继续补更多功能。 有了 harness，它才会被迫回到主路径。
Graph 让项目偏离了主线
MindForge 最明显的一次功能膨胀，是 Graph、Entity、Community 和 Sensemaking。
这条路太诱人了。
当你已经有了知识卡片，下一步很自然会想：能不能抽 entity？能不能建立 relationship？能不能做 graph view？能不能发现 community？能不能做一个 sensemaking workspace，让用户在知识网络里探索？
每个问题单独看都合理。Coding Agent 也会让它们显得更合理，因为实现变便宜了。schema 可以生成，repository 可以生成，service 可以生成，测试可以生成，文档也可以生成。
我当时的误判是：这些能力会让 MindForge 更像一个完整的知识系统。
后来让我警觉的现象是，项目看起来越来越丰富，但主路径反而不够清楚。
如果一个新用户打开 MindForge，他最先应该做什么？ 他为什么要相信 AI draft？ 他如何理解 approval？ 他能不能从 fresh clone 跑起来？ 他能不能在没有真实模型时先试用？ 他真的需要 graph，还是我只是觉得 graph 很酷？
当这些问题还没回答清楚时，Graph 做得越多，越可能是在逃避验证。
所以后来的修正动作很明确：Graph、Sensemaking、Entity、Community 降级为 lab/internal。它们可以保留为实验能力，但不能作为主产品能力对外叙述。
一个能力能跑，不代表它能写进主路径。一个页面存在，不代表它已经是产品价值。一个 Agent 生成的模块有测试，不代表它应该成为 public claim。
必须在 fresh clone 里重新走一遍
在自己的开发环境里把 MindForge 跑通之后，我一度以为项目已经接近可用。
fresh clone dogfood 让我清醒了。
当前工作区太容易藏状态。它可能已经有配置文件，有生成过的数据，有本地装好的依赖，有我手动修过的路径，有我自己知道但文档没写的操作顺序。项目在这里跑通，并不代表别人从 GitHub clone 下来能跑通。
fresh clone 暴露的问题通常不高级，但很致命。
默认配置里不该有 placeholder model。fake fallback 不能掩盖真实 provider 配置错误。sample workspace 的路径要正确。没有真实模型时，demo path 要安全可用。Web 和 CLI 的主路径要从干净环境重走一遍。
这些问题没有算法含量，但它们决定用户第一步会不会失败。
当前工作区 dogfood 更像开发者自检。GitHub fresh clone dogfood 才更接近真实使用。Coding Agent 很擅长在当前 repo 里继续修，但它不会天然替你模拟陌生用户。这个验证必须被人为安排出来。
测真实 Provider，也要把 API key 留在边界外
FakeProvider 跑通以后，还必须做 real provider dogfood。
否则我无法知道真实模型输出是否可 review，也无法确认 Web Setup、provider routing、secret handling、Wiki synthesis 这些东西在真实路径上是否协同工作。
但这里有一条硬边界：真实 API key 不能交给 Coding Agent。
这不是形式主义。AI Coding 的过程中，secret 可能通过很多意外路径泄漏：日志、错误信息、测试输出、临时文档、配置文件、README、commit diff。只要 key 进入 Agent 上下文，你就很难完全证明它不会出现在某个不该出现的地方。
所以 MindForge 的 real provider 路径后来收敛为：用户手动配置 key，系统只保存到本地 secret store；普通配置里只保存 provider type、base URL、model、routing 等非敏感信息；UI 只显示 masked 状态；真实调用必须显式触发。
real provider dogfood 是必要的，因为 fake provider 不能证明真实输出质量。 但 real provider dogfood 也必须保护 secret，因为工程验证不能以泄漏风险为代价。
这也是 local-first 的一部分。它不只是数据存在本地，还包括默认不联网、默认不读取 secret、默认不产生真实成本。用户应该清楚知道什么时候在 fake path，什么时候在 real provider，什么时候会发生外部调用。
READY 要由证据决定
Coding Agent 很容易把项目推进到“看起来 ready”。
我遇到过这种场景：总结里已经出现类似 READY 的判断，整体语气也像是可以进入下一步了，但报告里仍然带着 P0/P1。它们不是无伤大雅的尾巴，而是会阻断主路径或破坏安全边界的问题。
这件事让我意识到，AI 很容易制造“快完成”的氛围。测试大部分通过了，dogfood 大体跑通了，文档也更新了，剩下几个问题被列在报告里，读起来就很像项目已经收尾。
但 ready 必须服从证据。
修了没有？重跑了吗？是在 fresh clone 里重跑的吗？fake path 和 real path 分清了吗？secret boundary 还成立吗？文档 claim 和代码行为一致吗？
这些问题没有答案，就不能说 ready。
这就是 recursive remediation 的意义。发现 P0/P1，不是把它写进总结里然后继续前进，而是修复、验证，必要时重跑 fresh clone 或 real provider dogfood。
对我来说，AI Coding 的关键不是让模型一直写，而是让系统知道什么时候该停。
不把 Agent 的工作现场留在公开仓库
还有一个坑，不在代码里，而在文档里。
Coding Agent 很会写文档。计划、审计、handoff、ledger、dogfood notes、review report、architecture notes，每个单独看都像有价值。问题是它们堆在一起以后，public repo 会变成一个 Agent 的工作现场。
开发时这些文档确实有用。它们帮助保存上下文，记录判断，衔接下一轮工作。但从公开读者的角度看，问题就出现了：用户不是来阅读 Agent 的思考轨迹的。
用户想知道的是：这个项目是什么，怎么运行，当前能做什么，不能做什么，安全边界是什么，我该如何验证它。
如果 public docs 里充满内部 handoff、audit、ledger 和历史计划，读者会被噪音淹没。更糟的是，这些文档会制造一种成熟错觉。看起来项目有很多治理材料、验证材料、规划材料，但这不等于产品能力真的被用户验证过。
所以 MindForge 后来做了 public docs reset。大量 agent-internal process docs 被删除或合并，公开文档重新收敛到用户、开发者和验证参与者需要看的内容。
Agent 的工作记忆，不应该泄漏成产品文档。公开文档应该是少量可信内容，而不是完整过程痕迹。
最后一道门槛仍是用户验证
到这里，MindForge 的演进线大概是这样的：
先有 AI 个人知识库的想法。 然后收敛到 approval-first knowledge compiler。 用 FakeProvider 跑通工程闭环。 补出 Web / CLI 主路径。 经历 Graph / Sensemaking 功能膨胀。 把它们降级为 lab/internal。 做 fresh clone dogfood。 做 real provider dogfood。 清理 public docs。 最后停在真实用户验证之前。
这个停点很重要。
因为工程 dogfood 不是用户验证。
工程 dogfood 能证明程序能跑，状态边界守住，fake path 可重复，fresh clone 没有明显断点，real provider 主路径能走通，secret 没有被粗暴暴露。
但用户验证问的是另一组问题：
用户是否理解 MindForge？ 他是否愿意导入真实资料？ AI draft 是否真的节省整理成本？ approval 是信任机制，还是负担？ BM25 Recall 和 Wiki 是否真的帮助回忆？ Export 是否接得上原有工作流？ 他第二天还会不会回来用？
这些问题不能由测试回答，不能由 Agent 回答，也不能由我在自己的工作区里回答。
这就是 Harness 的最终门槛：user validation gate。
MindForge 下一步不应该是继续加功能。不是继续做更复杂的 Graph，不是继续补更多内部文档，也不是再包装一个更漂亮的 demo。
下一步应该是 3 到 5 个真实用户验证。
先降低安装噪音，可以由我预启动环境。让用户走主路径：导入 source，生成 ai_draft，review，explicit approval，进入 Library，用 BM25 Recall 或 Wiki 找回，再 Export。观察他们在哪里困惑，哪里不信任，哪里觉得有价值，哪里直接放弃。
如果他们不愿意 review，就回到 approval UX。 如果 draft 没价值，就回到 prompt 和 source processing。 如果 Recall/Wiki 没帮助，就别急着升级图谱。 如果 fresh clone 仍然卡住，就先修 onboarding。 如果用户根本不需要这个工具，也应该尽早知道。
工程上跑通，只是进入用户验证的门票。它不是终点。
接下来应该做什么
我一开始以为自己需要一个更好的 prompt。后来发现，真正需要的是 harness。
Prompt Engineering 解决的是这一次怎么让模型输出更好。 Context Engineering 解决的是这一次给模型什么上下文。 Harness Engineering 解决的是如何让 Coding Agent 在一个真实项目里持续做对事。
MindForge 从一个“AI 个人知识库”的想法，收敛成了一条更窄也更可信的路径：local-first、approval-first，让 AI 生成候选知识，让人确认知识，再让 confirmed knowledge 进入 Recall、Wiki 和 Export。
MindForge 还没有被证明是一个成功产品。它目前证明的是：当 Coding Agent 让实现变便宜以后，真正稀缺的是判断、边界、删减和验证。
Coding Agent 能让代码很快增长，但用户价值仍要靠边界、删减和验证一点点确认。